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Abstract 


Computers are unique in their ability to be prograared 
for a wide variety of applications. This is in contrast 
with hardware dedicated to specific tasks such as the 
telephone system. Because of its flexibility, a computer 
system can support, concurrently, m,any diverse services 
that do not require dedicated hardware. Conversely, these 
services act to bring the capabilities of the computer to 
the consumer who sight otherwise find the operational 
difficulty of running computer. progrargs too formidable. 


Since the computer is supporting many services which 
are sold to consurjgers it is natural to rodel the system as 
a marketplace for these services. Bost contemporary 
computer systems are oriented towards users who run 
prograas. The environrment for services puts different 
requirements on the computer systers than do the needs of 
programmers, So as to permit all the participants in the 
market to sake effective use of its facilities without 
requiring dedicated facilities and without interfering with 
each other. As with any sarketplace, it must be convenient 
to do business within its framework. 


The requirements of such a marketplace are not 
satisfied in contemporary ccm puter systems. However, the 
marketplace ‘can be~‘¢vé6ilved ‘“from:-sene existing: corgputer 
systems without’ furdasental changes. Presentiyz:-the: use of a 
ccraputer requites’ ‘considerable: expertise obrtheimart of the 
user. The evolution to a  sarkétplece:ds-mecessary if the 
capabilities of computer systems are to be made more widely 
available than they are now. 
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CHAPTER ONE 


INTRODUCTION 


Computer systems have evolved fro simple calculators 
to more sophisticated processors capable of running complex 
programs with large data hases, to inforaation systeus. 
serving the diverse needs of many users. Despite: the 
evolution of hardware and software ‘in the past twenty five 
years, computers are still regatded by many as esoteric 
devices for solving well-defined probless. One approaches 
the computer with a problem, programs the sachine (or uses 
an existing program), feeds in data and: the computer prints 
the results. This aode of . operation is being superseded by: 
one in which the roles of the computer and the user are not 
as well-defined, where the user works with the computer to 
find the solution to a problem. Even the idea that one sust 
necessarily have a specific problem in sind is being 
replaced by the view that a. computer offers a coklection of 
prograas which one. may call upon (through a command 
language) to performs tasks when requested. The tasks: may be 
one of those traditionally associated. with: the computer «- 
compiling, statistical analysis and «report generation ~-- or 
they may be used to cormsunicate with one's bank, library or 


colleagues, to manage household . finances, recipes, 
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scheduling, or shopping. 


These latter applications are not. common for a nurber 
of reasons. Some of these are technical -~ we often do not 
have the knowledge to construct programs: of the required 
sophisticaticn. Many of the difficulties are not technical,. 
but. are the result of designing computer systems for 
ranning programs. But being able to run a program is not 
equivalent... to being able -to make effective use of a 
computer. The vast sajority of computer users, as opposed 
to programsers, should not need to be concerned with the 
details of running the programs. By concentrating on the 
computer as a home for progrargs one sisses the forest for 
the trees. This thesis will distinguish between the use of 
programs and the use of services on a computer syster. The 
ain is to examine computer epiieas da: Gesse dor providing 


services. 


The evclution of computers from. programming systers to 
service systems is sirmilar to the earlier evolation fror 
the bare machines to those . with the support of 
sophisticated operating systess with their associated file 
systems, libraries and other resource managerent 
facilities. The service environsent provides the vendor 


with the facilities needed to enable him to present his 
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services to -his users without requiring: knowledge. of the 
complexities of the cogputer systea. The telestone systen 
is an exarple of a complex syster.dedicated to. a linited 
set of services. When placing:.a. telephone call, -a 
subscriber is using a yery ‘complicated cossunications 
network, but he need only state his: request in teras of the 
service he is: asking for. Normalkly this:.is- done by:sisupiy 
“d€ialing" the number of the phone.he-.vwishes..to: be connected 
to. In. addition .to. being. shiekded: fron: the technical 
complexities of the phone systea,; -he is:also shielded. from 
the financial ceapleszities and: the politics::af dealing with 
multiple telephone companies. All he. .sees.is.:a bill stated 
in teras of hgcee Wi acthads bes aakedaeoneeteresatans hae 
much in common-:with the. telephone systes in.- prosiding 
services to. its: subscribers, Hovever;: whibe; the: telephone 
system is: oxsganized around a limited: seti: of: services, the 
computer systerm.:is an environment in- whach aany . diverse 
services can be offered. As the.telephone . companies: have 
found solutions to the probleras of: providiag: their specific 
services, the computer systeas. -sust. provide an environsent 
that permits solutions to be applied- to a large:variety of 
services. 

fo investigate the .general-problems: of providing a 


variety of services within a computer system, this thesis 


i fs de 
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provides an enhanced sachine. The rost important 
characteristic of this environment is the availability of 
other services that may interact -with each other. In fact, 
the computer syster can be vieved.as simply a collection of 
these services; gore -being basic, such as the computer 
hardware and file . system, and: others * being more 


sophisticated. 


_A description of am environment for-offering coaputer 
-based services is incomplete without any discussion of ‘the 
financial oor resource | management ~ aspects ‘of the 
environment. In the design of computer systems the problems 
of buying and selling computer services have - largely ‘been 
dealt with in an ad hoc fashion. In many projects such as 
the ARPA network, they have simply been : deferred. But the 
viability of a computer system as..a sarketplace for 
services depends largely on the ability to transact the 
business of buying and selling ‘the services... To date, much 
of the discussion of accounting for computer: usage has been 
concerned with: the allocation. . of: costs:«:-for: the computer 
systema to its users and with the use cf pricing structures 
to distribute the computer resources: according to given 
pelicies. This is not, however, .the aim :of:a financial 
systea for a aarketplace. In the: marketplace, -the problen 


is one of. facilitating businass transactions, not: that of 
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devising appropriate pricing policies, except to note that 
prices should be based on measures meaningful to the user 
of a service. It is important to permit canveational buying 
and selling to he extended to -the sarketplace.: There is 


another necessary aspect to these ‘transactions -- the 
‘settlement of Aisputes. In typical computer - systens ‘there 


may be many parties to a @ispute, the  instaliation 
management, the prograaaers, and the user of the systern. In 
a parketplace,; each vendor..-can seke<: use . cof many other 
services. Unless. guidelines are wdateablisked for assigning 
responsibility when service is not. satisfactory, the market . 
hecornes unattractive to the user who -does not. enjoy the 
details of litigations. 


-fo Gemcnstrate the feasibility of the computer as a 
marketplace for services, an -isplesentation will be 
described. #ultics, a systen develaped ‘cooperatively by IT 
and Honeywelid, wili be used as the basis for such a systea. 
BHultics is appropriate because it. was designed to serve as 
a basis for a coaputer utility. The <isplenentation: of the 
aarketplace will . serve to: Gesonstrate techniques thet can 
be applied to other computer systems. The principle 
extensions to Nultics will be the creation an environaent 
for services as - opposed to progress: dnciadiag a. financial 
systea for conducting business in: the aarketplace.. 
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Once the framework of the marketplace has been applied 
to a single computer system, it can be extended to a 
distributed computer system such as the ARPA Network. By 
applying the framework of the marketplace to the ARPA 
network, some of the practical problems encountered in 


trying to offer services via the network can be resolved. 
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. CHAPTER TWO 


SERVICES IN A COMPUTER ENVIRONMENT 


The goals of a computer system ag an environment for 
services and those of structured progrdsmsing have ‘such in. 
common -in that they both represent attespts to control the 
ccm#plexity of computer systems by deco@pling ‘the services 
or modules of the system. Each so@ulde is viewed in terms of 
its interfaces .- with -cther . programs. “In ianalysing one 
programs the internal operation of ‘the: sindividual ‘prograzs 
it calls upon is net -:isportant. -Bachk -progrtam sodule . is 
considered to be fully responsible for the service it 
performs. Though one sodule may make use of ‘other services, 
the user of the sodule is insulated from. these secondary: 
services. While this approach has bees taken in some ‘large: 
programming projects, the facilities required for properly: 
protecting prograss "from . unwanted ‘interaction are 


inadequate in sost conputer systems. 


The computer marketplace and structured programring 
share the ktasic goal of making wore effective usd.’ of the 
computer systea. . The desire «for modularity steas from a 


need to debug a large program: by analysis of local 
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relationships between programs. For the rmarketplace, 
modularity means that each vendor takes responsibility for 
his service thereby relieving the « eager of . concerns about 
the details of the operation of the service. The ability to 
assign responsibility ia important sokn localizing bugs in 
prograas. One can. detenaine whether a-bug is in one's oun 
‘prograas or not. If not, then. the bugis either in another 
nodule ased in ..whick case, the -persan: teaponsible for -the: 
module can he informed, or it. is in the interface to the 
other module. In the marketplace,i:the clear = assigneent of | 
responsibility ia. necessary for daaleating : deficiencies -in 
services and for resalatian of disputes. .. 

If the computer: is to serve ad-a basin for providing 
services, an adequate ‘£ramevork aust ‘be developed -for the 
financial tranazections associated. with; ithe. .dbuying. and 
selling. of ‘services among ..the. participants - in. the 
marketplace. Hore then. -sieply~ :tmakiag:-it >; possible. to 
transact business, the .sarketplace: aust seke the ‘sale ‘and 
purchase of its services very convenient. The financial 
system is, effectively, a system of resource allocation 
simplified by the use ‘of a common measure i(aoney) for 
exchanging resources. -Unlike many -systeps for accourting 
for the use cf computer. resources, sthe financial Byates :f. 


the rmarketplace is not -weant @ieply asa seans of 
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allocating costs of the cosputer hardware, it must permit 
the assignment of value to resources created. by vendors and 


embodied in the services provided. 


The marketplace puts regquimerents on services other 
than those strictly dictated . by structured prograssing. If 
services: are to--be sold to :consusere = (as opposed to 
specialists ani sophisticated ‘gserg}, in..a cormpetitive 
market, it is important that the services be attractive to 
users. In addition to the characteristics of - specific 
services, general factors. can contribute. to the 


attractiveness: of services. The inmchude: <= .. 


~ Convenience: What is required of . the user to take 
advantage» of the. service? What ‘meat the user. -know 
outside of his particular epphication:area?- . a aC 


yee ote trp ae, P 
af Ag ne bs et ~ ’ 


~ Conpleteness:: Must the. user; iaccegs sultiple services ‘to 

accorgplish his:goal? Can he:iaecespligh the goal through 

the ese ‘of .a ssmall. ‘nusher ::cf s:senviices -that can 
scommunicate in a -cormrzron langtage? =: ».<: 

- Relevance: Can the user “speak” ito .tke -service in teras 

. Weaningful to his, of audt he: learn osose special purpose 


language? Is the service imterface"orsented tovard the 
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user's prcblem or must the user sake the problem satch 


the services available? 


- Safety: What risks must the user take in order to use 
the service? Is the service’so powerful. that a minor 
error can be catastrophic? Will ‘the user be abie to 
predict the effect: of his request? Does the: "principle 
of least surprise™ apply “-—~ Goes : the behavior of -the 
service conforsa. to that whith the user. intuitively 
expects? What assurances’ does the -use ‘have that the 
service: will be. satisfactory? If the: service . is 
unsatisfactory, what appeats does the user -have? 


_ The aim of. creating an environment for cosputer 
services is to sirgplify the offering -of sexvices.: ‘Some of 
the techniqnes.. have heen mentioned: above. The  priaary 
technique is the decoupling of services by requiring that 
‘the wendot of a service: take “complete: * responsibility for 
his service at the interface to the-:-service. This is a 
prerequisite for the ‘criteria :listed : above. The:service is 
convenient if the user need not be aware of ~the details of 
implementing the service. By taking full responsibility for 
‘his services the vendor gives: the-eser a well defined seans 
of ‘finding who to: appeal to - when any aspect of thee ‘service 


is unsatisfactory. The degree to which a user or vendor can 
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be liable in such a situation. can be limited by contractual 
arrangement between the user and the vendor prior to 


accessing the service. 


The financial system of the marketplace also supparts 
these marketplace criteria and is discussed in the next 
chapter. The problers of developing. standards and. design 
criteria for service is a auch. broadar-problea than. the 
design of the environment for services and is ‘beyond the 


scope.of this thesis. 


The availability. of -mahy services,...podsibly in 
competition, is necessary to provide a “critical sass" of 
service wherein one is likely to find a. service appropriate | 
for a particular task: or one can: find a set: of services 
suitable:for the. task. Services gust also be available: to 
be combined for the creation of more powerful services. The 
competition between services in the marketplace is a 
primary r,motivation for saking services. ga atheactive as 
possible. Ta provide an environment «in which - adil services 
can be made available to the consuser.in a uniform manner, 
it is necessary that the users and services share a comson 
pool of rescurces. This can.be done. by sharing a single 
computer systens or by establishing .. protocols for 


communicating between services within a . distributed 
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ccaputer systerm. In this latter case, the marketplace still 


appears to the user as a single shared computer syster. 


Since competing services are sharing a common computer. 
system, it is necessary. that they: can: be asserefi that no 
service can interfere with. any: other: service.* either 
maliciously cr accidently. Interference. can occar whah-a 
database is: altered, when a programs is: ‘stolen, or even vhen 
service is unavailable . because one user is ..exhausting. the 
capacity of the syster. The elininetion of unvanted 
interfaces sust not prevent normal interactions between 
users and. services. Both the vendors and:< the esers: should 
be able to control these interactiuns so that the vendor 
can Selectively. deny access to his’ weruice:.,:.so.- that the 
‘user Can prevent . the ventor having uneuthorized : access: .to 
the user's data ox soney,: and" seas £0 protect the: priwacy 
of the subscribers. ae a 


The computer system as ‘a (aur takedece i@bffers from the 
conputer ‘system as a -prograusing envirosiment.; To a ‘user not 
doing his own prograseing the systus::sust provide an 
interface to its services. The purpose of ‘this interface, 
which is sisilar to conventional comsané :processors, is to 
Sisplify the accessing of services and to: persit business 


‘transactions ‘associated with ‘thesé services to be sade 
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conveniently. Ccnceptually the user can be viewed as 
accessing the services from a typewriter-like terminal, 
though specialized terminals and interfaces are also 
possible. It is not, however, reasonable for each service 
to have its own unique mode of access because the user 
would be required to learn the idiosyncracies of accessing 
each service. Thus the computer installation must provide a 
uniform access interface to services. The user of a service 
can also be another service so that the interfacing 
protocol must also be suitable for use by a program without 


human intervention. 
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CHAPTER THREE 


THE FINANCIAL SYSTEM 


As explained in the introduetion, a viable financial 
systema is. key to the successfa]l. operation: of. the 
marketplace. The purpose ..of the financial .system is to 
permit standard business practices:..toa operate: within the 
framevork of the marketplace. This differs. from. the goal of 
many existing computer resayrce accounting:systeas as the 
emphasis is cn the transactions. betseen: the subscribers. to 
the. computer system. as opposed to regoveriag, the costs. of 


the computer systen. . 


The primary yequixengut for, ,the financial ..systen:is 
that users. have confiderce in it. .Coafidence requires. not 
only that the system be. secure aad. trustyorthy, .. but: also 
that the system be. convenient and siuple- erough to use: so 
that the user can be.at.ease. vith the system and-act worry 
about being:at the.mercy. of a: systea.fheat -he:dees not 
understand. The degree to which the.user. .can.trust:. the 
financial system depends, in part, on permitting the:user 
to apply his existing experience: with the conventional 
financial systea to ‘the new environpent.as.well .as on the 


correctness cf the algorithas used.and the integrity of the 
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computational methods used within the financial system and 


within the services offered. 


It is inevitable that disputes will arise between the 
users: and vendors of services. Bhless dispetes aré resolved 
fairly, the. participants do not have any recourse within 
the marketplace. in the case of unsatisfactory sérvice. If 
one must’ pay fet a service even when it has not ‘been 
provided satisfactorily, the risks: 4nvofved in sing 
services sa. outweigh: they «potential bénéFits.: Central to 
the resolution of disputes is ‘the-detétatiaation of who the 
responsible parties ate, for if teaponsfbility ¢ahnot bé 
assigned no action can be taken to rescol¥é “a d&fspate: Por 
the vendor, the recourse ina dispute may be to deny 
farther: access to his service. The? 4e6E° hay i Apply. Fisancial 
leverage: and Gany payeent’ antil- >the! issues* ate resolved. 
The. financial eyaten must “beable to*°protect the user's 
right~ to withhold the paynenté' > fer" s##vices. «In “other 
words, «the finatcial systes:: ‘is ‘a° sérvatit’ of the 
participants; paydeats® dre not sade. ‘and’ sefvices® “ard not 
provided without “this authérizdtion: by “the -£itérested 
parties. 

In day-to-day business transactions’ a‘ ‘number of 


conventions have beenestablished™ to: fdcilftate common 
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occurances such as the buying and selling of mechandise and 
to protect the interests of *participants. When the 
marketplace for service is within a computer system the 
methods for financial transactiéns diffetftos conventional 
methods because the transactions *® @o net “involve physical 
assets or produce written reco¥ds.-“It-may’be “arqued that 
‘one can continue to apply cttrent praéetices of using 
written ‘hotes evén “though “the: ‘Séfvices‘aré within -the 
computér system. This is‘ analogeas: to f@¢éiving a séparate 
bill ‘for é¢ach' “téiephone ‘cali one “sakes The burden of 
handling thé bills for-iéahy “small tradssetiséHs would: exceed 
the advantages of -such’ tangib%é ‘reeérdsi “In *fact, in 
conventional ‘transactions, “the problén: ef *“proeessing many 
paper ‘transactions is leading: “to ‘the* “de¥eiopment - of 


electronic’ fuitid’ transfet systems. == ==" 


The advantages of a‘ finaticial © system designed ‘for- tke 
‘marketplace’ is’ that it°chh “grehtly siaplafy the’ buying and 
‘selling’of ‘services. In dé@sigting ‘sééh ai system’ one ust 
provide counterparts to tradit#ona?” financial ‘safeguards 
“Such as giving ‘the subscriber coitrol over his own assets 

(i.e. no payments without seabseriber's:persisston) © and 
adequate records to give the stbseriber tae * equivalent: of 
such conventional recérds' as ‘retetpts,: ‘check: stubs: and 


itemized bills. Above all, of course, the financial systen 
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In the marketplace's financial system, one pays fora 
service by transferring money from the ‘wser*s account with 
the installation to the vendor's account. This transfer is 
really authorization to the installation manager to 
consider money formerly being held on ‘behalf of one user to 
thereafter belong to another user. A record of the 
transaction. is kept by the financial system and functions 
as a= receipt. A bill can © be considered the converse of a 
payment in that it is -a request - ‘madd ‘ty ‘a ‘vendor for a 
transfer of soney from ‘the -user's accotnt tothe vendor's 
account. For simplicity, we define a standard transaction 
as consisting of a bill and it associated payaszent. In 
practice, the bill may not be paid, or there may not be an 


explicit bili associated with the paysent. 


AS pointed out above, ‘the burden’ ‘Of ‘processing the 
bills from many ‘services can be gquite heavy. It is 
therefore necessary to ainimize ndnual ‘processing’: of the 
transactions. Most transactions are fairly standard and can 
be dealt with in a predictable,” or ‘automatic manner. It is 
only in the exceptional cases ‘that intervention is 
necessary. Thus one aust be able to specify what action is 
to be taken in the noraal cases and what conditions are to 
be considered exceptional and ‘thereby require ‘human 


attention. Simple. exasples of - avtomatic decisions . are 
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default limits for spending and authorization te pay a bill 


when it becoses -due. 


If the .specification of:.: how.. t@. process each 
transaction .is itself toa .. complicated, the advantages of 
automatic pxocessing of. transactions is.:-jost. fhe --basic 
interface to. the financial system qhould, perait, a. simple - 
specification of .. which. transagtions:.: cequize,  sanval | 
processing... the user. has the -poteatial of . programsing his 
own more . sophisticated screening of Ake tzansactions, but 
- standard transactions shonmld be. sufficient for most users... 
A standard transaction recacd wee described above: as 
consisting cf a request for payment (or .a bill) and the 
GOLrresponding pagpent...in addition sm, shese.two -iters, the 
traneaction record. containg a spenifigation., of conditians 
under. which -payaeat is to be automaticall, made. A sinpiec 
specifigatios dncludes -the .(fatexe); date -.on which payment 
is to be made and - the. saximas-emosat . of; prynent... This 
amount is. normally the -price the. veadar. quotes -vhen. the 
users. accesses @ . service. fhe auger; can Ahus Request. a 
service ani net hane to consider: the bill; individeally — 
unless .it, exceeds his ‘lisits.:Pf he serwice:-i8 pot 
satisfactory, he has eatil the -payagst dete he specified to 
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cancel payment. 


Grouping transactions together into accounts frovides 
the ability to ‘consider Glasses’ éf ‘tfansactions:s Rather 
than considering #11 -paytents to ‘be’ ‘Bade ftom one large 
account that the suabseribér has -with°tke -installation, | 
smaller accounts ' for specifié ‘ptrpéses “éah” Be maintained. © 
This has the advantage of permitting limits to be placed on 
each of the accounts so that an efref*#ill ‘nét threaten the 
user's total balance. Associated with'-@éaéh account are 
default values for transactions and total limits for the 
account. More importantly, the user“can délégate authority 
for-managing an acconnt. & ‘user can perait’a trusted vendor 
access to an account’ to célleét-pertodic“payments. He can, 
however, still limit the total amount that the vendors with 
access to the account can withéra’.  °{6f “edéurse,- this is 
against a background of contractual arrangements which may 
give the usér'légal* rights tdé-stil] ‘reétaid Kis ‘paysents if 
the vendor has not satisfied the conditions of the 
contract). Another advantage of havig¢*ultiple°aceouats is 
the structuring of the user's records #6: that he may more 


easily evaluate his financial position: 


The specification. of who can 46° what‘with a ‘userts 


account must ‘be fortialieed:s0"°that thé‘dser ¢an delegate 
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some of the responsibility for managing the account without . 
giving up full ccntrol. The ability to limit the amount of 
responsibility delegated to another subscriber simplifies 
the user's task of monitoring the use of -his accounts. We 
can define five roles which a sybecriber .can.have with | 
respect. to. an account. The subscriber's. sacceas to an 


account depends on the reles he is-.permitted.to play... 


Owner. $$ Hay specify .a subseriher's .access to the 


account... 5 


Clerk May examine the. -statys. -of...an-account . by 
-listing the balange and. any transactions 
associated with the account... 


Paymaster Bay authorize :payrents frga-the.accognt. . 
Receiver. Bay accept payseants..to.the account. . 


Requestor Hay -make .requests .for. paysents: fron. the. 
account. ae 2 

Roles must also be defined with. respect to. transactions . 
within accounts. A subscriber may be given the ability to 
change the amount fequested (i-@, specify the .amquynt.of the 


bill), cancel the. bill, authorize -payaept.. fagguming..one, has 
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appropriate access to the account with which the 
transaction is associated), or to simply examine the status 


of the transaction. 


The system of accounts, transaction records and 
controlled access permits the user to simplify his own 
processing of his financial transactions by being able to 
delegate some responsibility for their management while 
still maintaining overall control. For example, even when a 
user delegates authority to make payment on his behalf, he 
can limit the total amount that can be spent by simply 
limiting the balance in the account to which he is giving 
access. Typically he say give access to accountants or 


others providing financial management services. 
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CHAPTER FOUR 


AN IMPLEMENTATION OF. THE MARKETPLACE -— 


An important criterion in. the. design of the 
marketplace is feasibility. To. desgonstrate the feasibility 
of the requirements of the computer services and. the 
framework fcr the marketplace an isplementation will be 
presented. A detailed isplementation regedres: .: that: points 
‘be clarified. that are vague in: the. general: description, 
such as the exact rmethod of requesting a: service and the 
exact capabilities of the financial systeu. The MNultics 
system developed cooperatively .. by: the Massachusetts 
Institute of Technology (Project MAC) and Honeywell 
Information .Systeaus. will servye.as .the- basis for the 
isplesaentaticn.. See. Appendiz:-A -foer :a .description of 


Naltics. 


Aultics was designed toa: serve as. the basis: fora 
computer utility and thus cones.: closer to: seeting - the 
requirements of the sarketplace .thaa,: other - systess 
generally available. Multics can be extended without great 
aodification to .serve as the basis for. the marketplace. 
There are other systems that could. also serve.as. basis for 


a utility. These include IfM‘s: Ve/37?0iaad, O5/I9S2-2/TSO 
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systems and BBN*s Tenex system. 


In specifying an isplerentation - one aust first find 
representaticns for the elements of the sodel. 
Specifically, what. are the representations for the 
installation manager, the subscribers, services and: the 


financial systes? 


The installation asanager takes on- the responsibilities 
of the Sultics system adpinistrator. : The subsetibers are 
registered Hultics exzers.. : 


Services on Beitics 

A service is easentially any. sellable coanod@ity on the 
computer system. Gne may siuply sed]. access: to’ a date babe 
by subscription and then provide the service by giving: the 
aser access to the data. Sore interesting are services 
which actively perform a function: ana nust: « be: represented 
as a prograa for the conpeter. The: requiresents on serrices 
iuclede the’ following: 


- One aust always be- able to €etetiine responsibility. 
There must be no anadvertised side: effects. Sach* side 
effects are typically: the resgele' of sharing resources 
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without clear assignment of responsibility. 


- The subscribers aust be: pretected from. each other so 
that. one wauld not normally be.affected by the other's 


mistakes or attempts at penetration. 


- The user should consider the.service.to.be "black. box" 
and just view it as something. that: takes requests. and 


returns results. 


- The representation. - should. not. prevent a service froa 
using other services. 

o7 The vendors of -services. should ..be able.to control 
access. to. their.servicess: - 9 0 0 + a, 


- Services should be able to operate asynchronously. 


In Multics, these. requirements can be: met.. by running 
each subscriber's. programs in .separate, precesses, Each 
process is identified with the subscriber's princiral 
identifier. (or access name). . Thus .the identity of the 
subscriber cunning a given progras. can he. determined. at all 


times. , re mee: 
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Conventions sust be established for communicating with 


services. Since, ideally a service can be viewed as simply 


taking requests and returniag’a result,’ we can associate. 


with each service a° queue of requests: For @achquéeé’ there 
is (at least) one process that -redds -the requests and 


performs the service. The details of the implementation of 


services as processes associated with qaéties “is described — 


in more detail in Appendix B. © 


Process creation and communication between processes . 


via queues is not very expensive: in: Sultics, - costing 


approximately a second of processing tisze for’ each process: 


created. For many services, however, -this expense is too. 


high: ‘Instead of requiring its ovn process; a service ray 
be a subprocedure in the user's précessi There are a’ number 


cf drawbacks to this approach: 


- Since the procedure is being run in the user's 
‘process, it is #édifficelt: to @etersine. who has 
responsibility for usage of resotrces.: 


- Since the service and the “user's ~ programs share - a 
comson ‘#eory ‘(nore precisely - «e ' corkon address 
space), they can easily cosagunicate via shared 


storage. This use of side effects can obscure the 
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‘interface and thus make it.-:diffdenlt: to deternaine 
whether unsatisfactory: service. wasisthe: fault of the 


vendor 


- The user mest be willing: to trust the vendor's prograa 
siace it: will run . with: the same acecetssas. the user 
himself aad aay thns:- perfora actio&e:: in the - user's 
ake and without his agreementiir knowledge. This is 

‘ often beferted! to as the Tredan Horse: prohiem.: ©... - 
fa 7a. ts she Yo Foaven = &£ Qwateyedun ancidals: 

+ Because the’ weer ha’ access to! ewasine:) the vendor's 
“program - he can: eapily * ‘sake &@ : copp« of the « progras 

‘ < epoviag the calls to :the = ¢ixwncial myster (‘to avoid 
being ‘Chaty ed -for ‘using the sven dec ts peugr am iby: sing 
only the nodified copy. 

eit ne gpeta¢g2? Lsbioeranabe ad? 

There are some partial solutions to the probleas 
taised by attespting ‘to i-ren°a wedé@er'dspragram within a 
‘aserts process. ‘the ‘probien of) Bitlisd for x progres iwi ich 
“idy be‘taspezed with ‘Gan be rédués@ besedkking thie services 
of thé - prégrd#oh“é ‘subsetiptien Basie: odther:then charging 
for ‘each ivécation. | peas "sa Sfdeliae,. ciuskscdag 

Loe gee es : 
“Phe use of - the cingsof protecties i spensits :enesparty 


“to fun the: other. party's<ipregraes:cioa <a--restricted 
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environszent and. thus remove the .problem of mistrust in one 
direction. For example, if: the vender!s service. is: provided 
as an inner ring procedure, the user ray not circuaveat the 
vendor's protection, but the vendor may still sisuse the 
user's access privileges. Since. it. is very @ifficelt to 
provide more than one. inner ring : procefare: in a -given 
process, this rmechanisa is of. only ligited: atility.. In his 
doctoral thesia, . Schneeder: proposes...a:;. mechamisa for 
generalizing: rings to pereit the ase of}. anitiple, autually 


suspicious subsysteas in a given process.. While Schroeder's 


| ¥ouaine provide a viable rgeans - of; prosifing: some; services, 


they have nat. been implesented and: wild, therefore . not be 
explored facther in the description of the. isglenentation 


‘within ‘the qontert of :the exieting. deltics sgeter.;.. 


PPOGE sud wae. 


The Financial System on Sultics 


~. . ‘fhe financial system is a special service in that it 


is offered :cby the inatallation ;.managenest and-is. used -by 


nearly all .services and. thus; aust j:be efficient. The 


‘representaticn chosen is an: joner..-ring. (er. privileged) 


procedure available in all processes. In :Bultics there are 


eight rings. The innermost are reserved for use by the 


‘system-and: instaliation and can:-can therefere.be sed in 


all. processes even those that: -.azre- already using aultiple 
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rings. The use of an inner ring has the virtue of being 
simple and efficient. It also provides a secure financial 
system though it doesn*t protect that subscriber against 
errors in programs in the financial systea,'= a protection 
that is superfluous since, in general, one exanot protect 
against the installation sanagement.: Appendix .c . gives 
sample sections of. the #ultics °-Programners' Manual 
Accounting System Supplementiand: can be@=<referred to for 
more detailed description of the interfaces referred to 


below. 


fhe entry points for programs calling the financial 
system can be divided into three main groups according to 
whether ‘they deal primarily with accounts, ‘treasactions or 
services. For ‘accounts, the operations scomsist of creation, 
exawination, modification ‘of access - and termination. For 
transactions the operations are: .¢reatten; authorization, 
payment processing and requesting, examination and 
assignment to a service request. Service :réquests pass the 
specified parameters to- the -gervied. Sueh:a request might 
also specify a transaction which “the:service may use for 
its bill. The transaction specifies an amount authorized 
for payment so that the payment: can be made immediately if 


the vendors price is within the authorization range. 
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Accounts’ are coilections of data representing a set of 


balances and relationships with other accounts.. Associated 


with an account-is.a set of access privileges... The. 


following items are saintained for:.each account: 


_ balance..... 


This is a set. of paizs. of amounts and units 


. Eepresenting the balance on deposit. with the. 


_ installation manager... 


2} payables 


3} receivables 


4&) -access. list 


This is a list of transactions representing: 
payments from this account to another 


account. They may be pending or processed. 


This isa list of traasectione representing 
payment: to «kis . acceeat.>:from .-eacther. 
account. The transactions eay...be pending or. 
precessed. 


This is a list of .subacribers sarzes.and the 


access that each: has:te; the agcount. The 


- @@cess may bet. 2 fleece ud : 


owner. 


payraster 


Chapter 4 


The owner say set other's: access: to the 
acceunt. . ree" 


The payraster may authorize payrents from 
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the § account and =. change existing 
authorizations if payasent has not yet been 
made. 

requestcr A user who has access to:,request payment may 
‘ereate transactions: to: traasfer anounts: from 
this account to another. . account to which. he 
has receiver. access. ::. 

receiver Access to transfer payment to this account. 

clerk A clerk. may list: the. status.of an account. 


A: copy of each transaction record: is kept with both the: 
account to which and the accouht:fxom which payment is to 
be made. It can be retrieved by using the name of either 
of these accoants and its uniqae identifiier.- . The. 
transaction record consists of a bill: and its associated 
payment. 

When creating a transaction, one specifies a vendor's 
account, a. user's - account «ands an: intelligible « (i.e8: 
Enlglish) description of the transaction. The wouade may 
then specify the amount of the payment he is requesting. He 
may change his asgount so long as ‘the ~‘transaction is open. 
He freezes the ~ requested . amount: when he closes’ the 


transaction. The user specifies the amount to be paid to 
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6): amount paid . 


7} description 


8) whether oren 


9) access 


Chapter 4 
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requested, the amount authorized and 
the remaining :bakance in the account 
for the given units. Payment will only 
be made if the transaction is closed. 
If the acceant is‘open on the specified 
date, the trarsfer will be-sdde when it 
is closed =Once this. date ies passed, 
the authorization arount carrot. be 
decreased because the soney has already 


been transferreds: 22522. 


The amount paid sefar.. This represents 
paysent ‘which has boeed “transferred. 


An” intelligibte® ‘description df . the 


purpose of the transaction. © 


A status flag. ks long as the account 


is -open, « “=the > amount 5+ of : payment: 


“pequested may che wmodified.:.°. 


ag ae 


The name of the subscriber who may 


change the amount of payment requested. 
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The low level. entries into. the financial systen 
include entries to create accounts, create transactions, 
specify access, specify. quantities for payments and 
requests, and reading the eoneaneancnt transactions and 
accounts. These are described. in-appendix C. Appendix C 
also incledes ‘thd entries used: -toa-request services since 
the. finarcial . system -acts as --the ‘intermediary between 


services. 3 pe Galen <a 


It isn't sufficient to specify the interfaces to the 
financial systems, one must also be able to make effective 
use of thea. The aim ‘of the. fisercial ‘system eto de secre 
than permit transferee of noney :between. users. It is also a 
means of providing the subscribers to the marketplace with 
control. over their -fineacial | dealings. In as envizoraent 
where there are -many transactions: ‘being nade, effective 
control means not only that the subscriber be able to 
@ecide the: fate of each transacttan, ‘but also that. he is: 
not swamped. with details that .<weuld render him unable to © 
deal effectively with .ieporten t ctemmeections. Some exanples 


of simple transactions: 


. Case one: a user -purchases‘a.: service and pays in 
advance. This is similar to a conventional cash purchase 


except that a record is made of the transaction. The user 
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asks the financial system to make’ a ‘payment to the vendor's 
account. The user then sends the ‘service request to the 


vendor along with the identifier of the transaction. 


Case two: a user purchases a service but does not pay 
immediately. The user’ way “sieply' pass parameters to the 
service and the’service’- will: in turn” sikke: a ‘tequest for” 
payment to the user's account: th -Stder to ao''so, the user” 
must give the vendor access to sake paysent requests and 
then must consider the request “to decide whether to make: 
the payment. A simpler procedure is * for’ the’ user to create 
a transaction and’ “then give the’ vendor access only to the: 
particular transaction. If*the set’! expects the service to: 
be satisfactory, he may specify a maximum payment for the 
transaction anda date on which the payment is to be 
automatically sade.  Thes, “usless ithe" service is 
unsatisfactory or the bill is higher than expected, the 


user need not be bothered with-° deciding’ on payent for the 


transaction. oe 


Case three: A’ user wishes*to pay a grotp of vendors 
automatically but limit the tétal ‘paymeat: This is useful 
in paying utility bills such “as°gas and ‘electricity. The 
user can create an ‘account for this putpose and give it a- 


balance equivalent to the ‘haxiea® allowable payments. fe 
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inns 


KS access; to. make 
payments to themselves and. does net .need . to; check. 


can then give the appropriate. ve 
transactions. individually. 


To make. most effective. use. of. the. marketplace, bigher 

‘level routines: than the interface specified ia the append: 

@ would. be. necessary, These . interfaces; wpeld, take, care: . of. 
many of the details -asgociated; sith, standard transactions, — 
For example, instead. of explicitiy. specifying. 2 date for. 
each transactions, the routines. veuld; aopmadly supply. .2. 
default date. such.as.: the. end of.,..the, gaer's .next,pbilling: 
period. Protocols, for, sore, complicated. arrapgeueats. such: as: 
the use of. cre@it..from..a third . party... apst -aleo.- be. 
developed. 20000 ver 8d yoda dele 


a, 
Fs 


oar => Bpltics.ag:a servige;systeM@,;, 666. Focus is 

ee ee Pepa wt Seo wes. AO MESS ea ees 

The standard .asex, interface, to, Apiticg.is¢.. a command, 
processor that is used to invoke programs. To the: psex- of--. 

the rarketplace this is unsuitable anda sore service 

oriented .interface, is. necessary, IB. ; ging,the service 

interface, the user. need:, oply,. specify; the; services; . he.. 

wishes to use and the.. paranetess for: the; service. . This. 

interface,also. incledes the .highes.Jexel, acsoueting. aids 

neat ioned. above. In... practice, this, iatexfage, night,..21s9,, be: 
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used in conjunction with special consumer (as opposed to 


programmer) oriented terminals. 


To illustrate the characteristics of a consuaer's 


ee meres 


interface to the narketplace, a script yet be presented. 


The _burpese of this script: ‘is to Present: the reader: with an 


e 


overview of the system as described so far; the example is 
not. meant to demonstrate an ideal interface. For simplicity 
in presenting a script, a typewriter ‘Bikestereinal will be 


ti SNS 


assumed for the scenario belov. ‘the scenario -is very 


ii yo “Oy fe egopgye tad 


wl 


limited <i: that! ‘fe doen: nos: ‘pexplore: the Ksaoarot- ance 
interaction that might make the: Suse of: Sénvice:<mach sore 
convenient, but is: aeant as a ismell: pod ames ef. the use of a 


service through the aveien: 


The user's aT PPEAg is underlined and the coaputer 


2 ee ger isdigrt 
systea"'s - outpat - ie “not underlined. -Couneatary on the 


[3 GR Pye se 


scenario follows */7™ “dese ye ony 


Welcome to the Scenario Marketplace 
Date and time: January 1, 1975 2t4:00:-ae edt =. 
Deteurt ercount: "Hisc Bills" 
ee ven eech tedt pasos 
It Host: Négkeactlone thaw iauck inforaation in common 
which need not ve: Suse leew eens te each tine. 


Default Payaent dater 2 months! ("anch ty 4975) 
// the date on which: payment aekiit noreedly be sade 
Lf no further action 48° taker The asount of the 
payment will be restricted to the default linits. 
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Request: account supmary 


// This is a service which helps -manage . the -user's 
accounts. 


Bills paid recently: 
f/f Anount Service Description 


$50.00 séveuagazine 1975 ‘Subscription 
$18.97. -Electric Co - -Nowesker 1974 Service 
$ 2. 34 Retkecriece Service -ceaxae November 197% 


Bills maturing ‘soon: 


1 These are printed as remindere to the subscriber 
-80 that he carn.cancel payseat.fogr those services 
that were ansarintactory or are inccapiete. 


oye ir E act £3 Su BRO? es “5 9 a 


$34.32. ” “Reference. Library January "3, 1975 __ 
$32¢82:. Genexai ‘Pregrasningsdanpary:$,:1975 ; 


‘Wov receivables: overdues. 


. ff To heep: track. of- si euaakeiwueston the: subscriber 
in his role as a Senne 


Request: gead gail 


No mail. 


ZZ A typical use of the marketplace We. Gueuntestion 
‘with: other sabperibers.:~ Thig; is: aa: ezagpi¢..: of a 
service which is small enough so that the user is 
rarely concerned with pepeging. | the ~ paypents 
directly but instead sets a predefined ‘Linit and 
does not request any notification at all of the 
transaction. 


Request: Poogsgrket : peters see 24% 
Waa ik ope Plus te 

// Shopping that Aeon. aoe eaaive: ‘actnal handling of 

+ jooés: can be. done via the eompater, system if it 

is convenient _enoughs :-n :-this!--exarmple, some 

explicit interaction with the financial syster 

“must take . place. since ;.-the:aaonnts..-of money 

involved exceed the user's default ‘Linits. For 

-: the purposes . of thie.) acenario,, Jines . beginning 

> with 2" @re conaaads: to a itaeiqinni system as 

: Opposed to the servwice..- ©: ny 


ay get ~ Pa a eee 
rine sad eet wo cate 
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Do you wish to change-your standard shopping list? yes 
change, add or delete? change 
item? milk 4 liters « 


// Remenber that the purpose. of: this: scenario: is not 
to demonstrate an ideal interface, but just to 
demonstrate: how one: wight deal with services. 


‘Warning: Default. authorization’ is:) $82,00,: 
Cost of items is: $34.39 
Transaction: is “groceribs:01 07.73.1349 


*authorize groceries:01.01.732134 $34.39 


// User authorizes the increased amount. This does 
not’ hecessard ly: : anthcive: demediate:: payment. In 
fact, the user is able to change the amount at 
any time uatil the -Boneyia actually transferred 

to the vendor's account, but chooses to specify 
-the asount': 00: sO #hat theic #ijl: not: need. to 
examine the transaction again. (The "**" is used 
in the -erapple = to gean,: that the = command: is 
directed to the financial eer Farser than the 
servite, be: accesseagi ). Bee Pe PLS Ss APB LS re tery Se A 


Request: sie. re eee 


Since the aeapeneeey syaten is_ So central to the 
marketplace, it must be very reliable. It auet also provide 
SEG i {DS a Fudd Xe 


convenient facilities for subscribers to monitor ‘their own 


PUSGay Bie S 


use of he market. Tn addition to the file agaten integrity 
features of Hultics, records of teassuctide ace nates in 
duplicate, one copy with the account from which payment is 
being made and one with the account receiving payment. In 
each record is sufficient information to locate the other 
copy of the transaction. Since the two copies are on 


opposite sides (i.e. credit and debit) of the account, the 
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total amount of any measure is. ‘Cconataat in the. saa hd aca thus 
providing a checksur for the finsacded eetebs A Journal 
can also be maintained: of ail “events effecting the 
Financial: syste. “this journal is inportant:, for upda ting 
accounts frorm earlier. version: - day the: caper of: ‘catastopic 
failure and. for. resolving disparities . - between transaction 
records in two accounts. 

the user is: safeguarded: by. the! avadaability: of records 
of all his transactions. To be intelligible, they all 


oc 


contain description: of | the “transactions: ‘Since all the 


rc 


transactions are online, the user’ wap easily “ase prog raas 


aan res 7 Lge 


for this uatiagonent process. (For: = uaa pia,2 hav ean supRmarize 
his payments by categories cr other criteria,: Having ali 
the records available is a mixed blessing since 
unauthorized disclosure can be a serious anvasion of 
privacy. nultics offers the eeehiical means “of P protecting 
the | records, but legal protections aust ; also ‘be provided 


for misuse of “the "records by ‘the installation manager and 


by es “ke may have. access to read ‘thea. 
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CHAPTER -FIVE 


DISTRIBUTED SYSTEES: 


A network of coaputer systems linked via communication 
lines can be considered as.a _ siangie distributed systen.. 
Lesser degrees of distribution are also ‘possible, ranging 
from a sultiprograaming system where: -the- precessing is 
distributed by the software over: a number: :of° logical 
processes, to sé@parate- computer -systeas sharing storage 
facilities, to separate conputer:~“systeasivith: agtononous 
administrators who cooperate through a small set of well 
defined protccols.=So far we have considered only ‘the: first 
case, a singie .-pultiprograaning:<.° {and.::: possibiy 
auitiprocessing} ~systea that: is: viewed .as-a hoaogeneous 


ehvironment for compater servircess: ~§ os 58"55 


“To the user requesting a service, it is. not: iaportant 
where the program: for the: service is* being: run; as long as 
the -interface. to the . service. : is: weil defined aad. the 
parageters can be passed without .coauplications. Before 
considering the-ramifications of: -extending: the msarketplace 
to a distributed system, we must’ first: examine the reasons 


for having .a distributed system.) 
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To the consumer, it is ehoonventent to use multiple 
markets. The ccoaputer system can be compared with the 
telephone system. A telephone sabscriber doesn't purchase 
services directly from each phone company. Instead he 
subscribes-to .one phone corpany shich  provides:hina: with 
access.to the subscribers of the other phone corpaniess To 
the subscriber; the teleshcne-:systes. appears. to be ..ore 
large. -netwvork. without the conmpiications: .of many 
interconnections: and differing tariffs...In the sane: wanner, 
the subscribers: iocal. sarket:can: servye.asz:his entry. isto 
the: larger system of marketplaces. © =u 9 © 

Unlike two--subscribers of: a. telephone systen,”. the 
communication: betveen..a: asexoand: 4) sender. is: not restricted 
to a:single set:of: coaventionss ‘Ins addition: te: parcaseters 
explicitly presented. by thecuser «to: the: vender and resinlts 
explicitly returned as messages, the two parties ray 
coakenicate via: shared. resources: ontedde: the scope of the 
restricted protocol: for accessing: services::For - example, 
the user may. present: data: to: the. sender: by: pamsing: a: percry 
address to. the vendor. ©The vendor: vould thea access the 
data directly in this shared nenory, °§ hile this say _beia 
simple operation within the confines: ofa ‘ singie’ compa ter 
system, it is rsore difficeitto:. extant: : thd .: pode ~ o£ 


communicaticn to a distributed systerm. For the purposes of 
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discussion, we will restrict comgenication between the user 
and the vendor to: an access: pratocel wherein the user 
passes messages to the vendor vila a gueve. of requests for 
the vendor's service and the vender replies by sending 
messages to the uger via a similar queve-used for replies. 
Tt should be noted -that the name ofa service «may be -passed 


as a message. : a eh tet ote 


As in a ‘single system sarketplace, financial services. 


gust be provided. . As long. as: ‘ahe -can.=provide a. secure 
environment, . interfaces. similar: ta these; specified in 
chapter four can be pravided for a: couneas : financial system. 
When there: are autenosous:adainistrators; =the. approach ‘of 
having:a single financial: system :cannet:be::asedysince -the 
/participating . installations are :wutualiy- suspicious. The 
relationships between the instalid#ions: sis-analogous. -to 
that between services at a single installation. Each 
installation maintains:.an aqcogat representing. its;status 
‘with: respect to: each: other: instaladation..: Bexjodicaliy the 
-installations sust: make. actual: cash: paya@ats:. to - resolve 
imbalances. a oe ee ne eg tour 

When a -user authorizes: payment. .to the vendor, he is 
telling his. -installation. to: authorize: payaent by the 


vendor's installation to the. vendors: If the veador's 
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installation makes this payrzent itis, in effect, trusting 
the wserts “installation: to-make ‘the -payment when the 
accounts. are resolved. -This requires that. each pair. of 
installations establish a credit relationship. -The nurber 
of such relationships’ qrovws with the square of: ‘the number 
‘of... sinstallatbeas;: The. - cmaipstwinesice fo+ef - maay:..: such 
relationships is cumbersonre. To reduce the; -nushber of 
relationships, an intermediary can be introduced as a 
‘clearinghouse for .the transactions. between installations. 
This clearinghouse. is felfillisg-sieilar fenctions ta the 
installation manager at a-centralized<sarketplace, with -its 
associated benefits. Just as ithe *: pregence:af a:sarket place 
“financial systen-does ‘not -.preekade:speciai: aprangerents 
between venéours, use of the clearinghouse is! voluntary, : but 
is a requirement. for . keeping «'deakings:. with.  .ather 


installations sanageable.: poo oad saewted achder 


-'° Phe: ARPA’ Wetwork as-an exzanple> ‘of :sa distributed 
“computer syster. It is: composed: of: aatonononus: -conputer 
systems linked: together through: <a: sessage.. Switched 
comaunicaticn syste. The isportance of the network: isin 
its attempt to define protocols to permit. the cooperation 
among users. of these diverse: : cospater:: systeas.: These 
- prototols havecso: far been painly concecned with the:nse of 


- Yesources at one cosputer installation: : by! users at another 
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installation. The network has been used by same subscribers 


to purchase setvices from reste instal lations. 


In order for a user to access a resource on a computer 
system he gust first sake arrangesents ‘to pay: for the use 
of these resources beforehand. This requires that he either 
have an account with that couputermcmstallation or that the 
installation . provide a comaon avrount “for network users 
without charging each one individually. For many users the 
difficulties of making special arrangements outweigh the 
advantages to be gained from such sharing. It is also 
difficult for a service to make transparent use of the 
network, i.e. if a user calls upon a program at his local 
instaiiation, the program cannot make use of a service at a 
remote installation without the user having made prior 
arrangements -- the user cannot treat the service as a 
"black box" but must be aware of the services it invokes in 


turn. 


A financial protocol can be established to facilitate 
the use of and payment for resources at remote 
installations. Each installaticn on the network is, in 
effect, a marketplace offering services to its subscribers. 
The financial protocol permits financial systems at two 


installations to request and authorize payments at. the 
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other installation on behalf of: their subscribers. The 
protocol provides both installations .with. capabilities 
equivalent to those provided to the subscribers within a 
Single installations. The messages passed between the 
installations correspond to the .fanancial systerm entries 
described in appendix Cc. The: accownt and: service nares 
vould, of course, he expanded: to: include the adentd fication 


of the installations at which the. nase::ia defined. ... 
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CHAPTER: SIX 
CONCLUSIONS ‘AND COMMENTS . 

The aim of this thesis has been to explore some of the 
difficulties that have inhibited ..:the growth of 
computer-based services and the. converse problem of how to 
make the capabilities of computers: available to users. The 
soluticn to the problem of making more effective use of 
computers involves a:coabination of coapiiter ‘technology arid 
human. engineering. The “thesis. -thus:/addresses both 
requirements for a -consumer- oriented ceaputer -sysSten ané 


for'‘the technology needed for its inplesentation.> - 


Supporting services -involyes2naoré* than: just writing 
computer programs to perform specific applications. The 
services must be provided within a context that permits the 
user of the services: to be unenertabered: by the :coaplexities 
of conputer systems without givdéag-ap ithe: conveniences that 
he’ is ‘accustomed to with: ‘mere conventéénak?services. It. is 
important that hé have confidence: £a*the: services. ‘and: in 
the ‘market plece. “This -confiden¢eeée:* depends on) -a- user's 
ability:to* predict the effects of: his actidas and: on his 
ability‘to protect what he considers:to:be Abs: rights ot ‘at 


least to limit his risks. ©) ©. © SHS 
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For the vendor, the rmarketplace must provide an 
incentive for creating services. The marketplace, by 
permitting the vendors to:-seli: services for a profit, 
supplies some of this incentive. Competition within the 
marketplace helps ensure: that. the :-services: sold will be 


attractive:-to users. 


Disputes will. inevitabiy arise. aad:aast:.be easy: to 
resolve in: conaon cases. Rundanentai: ito; this:resolution is 
the assignment ..of rcesponsibility«:A; terndor: must take 
cosplete.responsibiiity for: his service:both: to: provide a 
simple (and therehy attractive} isternfage and to -give.the 
user someone whe-can-he: hekd accountabie for ‘unsatisfactory 
service, even if the ultimate cause of the problem may be a- 
secondary: vendor’ who: :suppliesia zbasic-:service: to the 


primary: vendor... pee Peg A BS eto des dace 


Basic. to a ‘free: market:. is: a: trastrerthy: ‘financial 
systea. Unless. the subscriber,.can :have:confidesce: in: the 
financial] -systes,..he: :canpot:: sake: e€fectise: use of. : the 
marketplace. As. -stated. .abowe, -:coenfidence: -requixes 
predictability :and:safety.: By: cbuiiding -Bpeh. the: user's 
experjence: with: conventional business -transqctions, : the 
financial. systes -of-the:earketplace:; cis intended. : to allow 
him to have enough of an intuitive: knawiedge of -: the 
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financial system so as to be able to predict the effects of 
his actions. To protect his rights, a user aust be able to 
selectively deny payzents to vendors: am # way of protesting 
unsatisfactory service. But it isn't. enough for it to be 
péadtike for. the user to exercise control, it must also ‘be 
easy to do sc. To prevent the ‘user from being swamped by a 
large number of transactions, the financial system provides 
capabilities that permit - him «to * automate his financial 
management and restrict his ~ attention ‘only to the 


exceptional situations. =~ * a a) 


The marketplace, as described in this thesis, is 
feasible to implement. within . present«day technology. To 
demonstrate this feasibility, an: ispherentation has’ been 
described baseaé. on foneyvellts: ‘Wultics --systen. © While 
changes are required to the System, these are relatively 
minor and do not affect the basic structure of Hultics. The 
changes need not even interfere with existing methods: of 
using the systea. The implementation ‘has: been: extended to a 
distributed system since a large sarketplace * would: exceed 


the capabilities of a single ccouputer installation. 


. The thesis has, by necessity, *§ been limited to those 
topics immediately relevent to ‘the implersehtation- of the 


marketplace. Many of the topics:: that were mentioned were 
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explored only to the degree necessary to establish that the 
difficulties they presented were sureountable,. but the 
solutions were examined, in only - a.;ommsory..fashion. The 
prime omission has been a_ full discussion. of the interface 
to the consumer except where used: in-examples and vhere 
used to define basic . requicerents. « for: the low - level 
interfaces. She omission has heen intentional - because our 
understanding of: the cselevant: isaues ..has; been. Jinited. by. 
the currently aveidable envixconment::for such - services. - 
Given the environment of the market place,:cepearch: : in the 


design of the services themselves can be carried out. 


Other. topics. ealteeedadinke ite -—egad: aspects of the 
marketplace, the .detaiied: iapiamentation of: - the: financial 
systes, and the limitations of: ao mgstem supkas Multics. as 
a basie for a marketplace: The ;Jjegal yaetions faced.in the 
marketplace involve the -probleaam of . culem governing | the 
market as a whole -- should... it:-:he - regulated, what 
constraints are there on the: inatelilatton . aanagenment;. and . 
the . problemas .of.: relationships: . hetween->s9ers. -- what) 
contractual. arrangesents are appropriate,: what: japlicit. or 
common law obligations do the parties have? The financial 
system, must. he verg... robust.-(i.e -dimmme to - catastophe), 
even: though . the: environnent:: in: shink it) can aay aot. -be 
very reliable. Hultics,. has:-baen desiqned asse . basis for a 
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computer utility but suffers from some of the same errors. 
of omissicn as this thesis. For example, is the systen 
sufficiently reliabie; is the security s¥stea appropriate 
for the “real world” when the .walvwe ef -breeching it is 


high? Barak 22 dy teen anal 


Beyond the detailed issues of the marketplace are the 
questions of the isplication-of the. marketplace as a 
mnictecosa of _an econosy and tke relationship. “between the 
marketplace and society as a whiele.«:What mare the -effects of 
mapping “existing institutions «suck ‘as: banks,. credit 
bureaus, insurance, - congunications systeas . (including -the 
pest office); etc, into -a-conuputer  systerts sarketplace. 
Senne of the froblems will be intrinsic to any ‘marketplace, 
but others will arise from the nature: of ithe computer 
system. For example, the consumer =:would not be constrained 
ty geographic consideratiois:in: thecsésection:of -servicess 
He will-dlso ‘be. able:tovise the cosputed iasoan intergediary 
between himself and thé services he is. using.» He aay, for 
example, have a program which gives him a personal record 
of each transaction ‘with a ‘given. :service.-An.:isportant 
consequence of. the low capital necessary to create a new 
service is the opening: of the narketplace .to hordes . of 
small*entrepreneurs. Whatcare thecadwantages -ofssuch,a:filea 


market? What are the disadvantages? hat: -reghlations: are 
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appropriate? 


The social effects of such a sarketplace are: hard ‘to. 
foresee at this time. We can only speculate. It. is possible 
that such a marketplace can become a significant social 
factor since it provides a very good environment for many 
services especially thase. tat ©-involwve ; comsunication 
between people where sone. intelligent: precessing . is 
necessary. The cusrent isystesz of). .baake and credit -ageacies 
is an ‘6rasple. The sarketplace. is .also --guitable for 
services that require sisple, but . personahized :processing. 
sech as catalog skopping-or library services~:Both of .these 
also ‘rely on the-ability to. comeunicate with a shared pool 
of information. The effects of ledsening :qeographic and 
Bational restrictions’ on information. sharing -a2est - not -be 
overlooked. This is an-extension. ofthe information flow 
nade ‘possible hy telephones: and-aizrplanes.:» Finally, vhat 
are the-‘isplhications of . globabay>isaveialeble- technical 


expertise, as supplied by coaputer based: services? 


ve Wi tor 
BoM I Es 


The marketplace model of the! computer...system is an 
idea whose time has cone. The costs: ¢f-:;compnter hardware 
are decreasing so that-the necessary computational power is 
becoming available. ’.In fact, © the:mafor. :cost.of. coaputer 


hardware today is the overhead’ of. new:tesearch aad support 
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supecadl: As more hardware is sold, this cost can be spread 
thinner. Software represents a large portion of the expense 
of a computer system and the expertise for developing 
computer services is a scarce resource. The marketplace 
framework eases the burden of development of computer 
services since it permits the development to be 
decentralized among individual entrepreneurs, although 
although the availability of the marketplace will not cause 


the probleas of implementing service to disappear. 
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APPENDIX A 


- Description of Multics 


Multics, asa systea, jarearus two main functions: it 
distributes computer resources... among the users of the 
system and it: provides an environasnt for running: prograss. 
The resources consist of the hardware and the software. The 
hardware is sade up of procesSsors,: nemOry,:, aaSS storage, 
cogtunications facilities and:: other peripherals. Minizal 
distinction is ‘aade. between. the systen: software ant the 
user software. ©The system. coasists of .a. privileged. 
supetvisor which supports the’. virtual sesoery.” environment 


and. manages: resources, ané'a non~prisiieged: portion.. 


The running prograags are organize@ into: processes. A 
process is equivalent .to a job. ox: a <task:. in comson. 
operating systeas.: It is @definek by :.an-exerution = point: 
(i.e. a location counter) an@ a.aapping of: nazes in tke 
. storage system to adaresses in © ‘the processes ; memory. The. 
address itself consists of tvo Parts, a seguent: ‘nusber and 
an offset within the segment: &: segeent:-is, as its name 
‘implies, a piece of memory and generally corresponds toa 
single program or a data file; Sultics makes: no distinction 


between the two. Two processes referencing the same seguent 
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may know the segment. by different numbers, but will 
reference the same data; if one process changes a word in 
the segment, the other processes: willbe able to read the 


hew value iamrgediately. 


The storage system corresponds to more. traditional 
file. systems, The important difference.is-that once a 
segnent in the storage szetem has: bean initiated. ("opened") 
by a process... (either explicitly or imphici¢adye it becones. 
part of: the directly addressabie: neaory. of . the. process, The 
storage: system. consigte of segments ,- ; aad -gatalogs Of. 
segments called directories. A directory say. :adeo: contaia: 
other directories and thus the . storage aystenx forns a tree 
structure with the Jeaves being dizectonten: and: segments... 


.- Segments of: memory fore the baggie for «the controlled 


sharing of information. Bach process has eamociated with it: . 


a’ principad itdentifden < (om, acnese: 34); thats = is formed from. 
the wuser‘s name. . Each - se grent. i: jraec a ,adietc of £ these. 


identifiers: and what: aceess each: han to the segnent.: Thus. 


cue: nser aay be designatei as: having access >4+0 read) a: 
segauent while another may: also white data into at. §. 2 «=: 

Multics extends. the. concept: ! of: -sufper visor. and: probiler 
states. found in sanyp. oprating = eyeteracto.ca aultileavel: 
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system of rings. There are currently eight rings in 
Multics. The aost privileged or innersost ring is ring 
zero. In © designating access to .a segment ohne - may specify 
the rings in which the aceess'is available. If one, for 
example, designates a procedure ‘te be -=teadabie ih rings 
less then four, but only writable in- rinys: less! than three, 
the user in ring three aay then: wee the’ segment normally as 
long as he is not sodifying its. To wodify it, he ®ust call 
a program in ring two or below. This ring =two program may: 
then check the user's request: for validity: aad, in effect,” 
exténd the hardware access contrel: sechanise®: by: providing: 
arbitrary mechanisas via sof tvarel: For! example,: access to a. 
data base may be via an inner ring procedure which will 
return aggregate values, but not permit an individual iten 
to be examined. data item. The limitation of inner ring 
procedures is that, if they ave mutually suspiciots, not 


more than one can be used at a time in a single process. 


Multics administration consists of three levels: the 
system administration, the project adaninistration and 
users. The systen adainistration is in charge of 
maintaining the system integrity, creating projects and 
registering users. The purpose of registering a user is to 
guarantee that his user name will be unique throughout the 


system so that it may be used as an identifier. 
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Registration, per se, does not give the user access to. the 
computer-systea. This is done by. the project. administrator. . 
The project. adainistrator can: desigeate. a: list. of: users vho 
may legin using bis . project's -.name, .The project. 
administrator .ie responsible. for..the xesource usage . by. 
those: on this; praject.,; He; may aleo -specify, individual 
spending. liaits.for. his users... Users aay: excercise control. 
over access. to their resources. by: spesdfying - which. users: 
may have. what., access to thes. . For . example, the. ,.access. 
control list associated with ©. sequent. specifies, which. 
users (ex; prcejects): sey. read, write,..or extend. the. segment... - 
The access, may be different. for: each: nsere: 


as be Be 
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APPENDIX B 


Implementation of Service Queves on *ulitics. 


Chapter four presented a s0@el of a service as a queue 
of requests and a server for the requests. Such’ a facility 
can be implemented with: sininal: ‘cheage: tod sultics. The 
following three facilities provide a sufficient. basis: 

1.’ Message segments. Message segmenté are queues 

- Panagea by inner ring = syste proceéures. The are 
implemented using segments in the storage. systen, 

» but users’ aay only access: thea throegh: ‘these systen 

-<- procedures,’ Users’ way have: avtees to aid entries to 
‘a queuey’ List, ' reat and deletes t oc Own entries; 

and to list; Tead .-‘an@ delete ~- atic entries. 

» Associated: with each *>emtry “< ig’: w= secure 


» fSdentificattion of the user! reating the entry. 


2. Multiple processes. Multics users may currently 
hdve processes cheated ‘on ‘Heir teha¥e fo use this 

"! facilaty, the .yser] ends ‘ai deusoription': of ‘the 
-i. process’ ‘to ‘be ‘created te <ew° wbsente’® -process 
coordinator via a‘ sessaye.: seguent. The . absentee 


‘ordinator ‘schedules the provess: to: bie created as: 
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if it were a job ona batch processing systen. 
Process creations are deferred until the nurmber of 
Processes created. in this manner. is-.below the 
maxigum allowable. To make effective use of 
services, it. is necessary: to.ease the restriction 
on the number of processes that. say de created on. 
behal: of: users... This... restriction:is. preseat mainly. 


to siaplify resource schedgling... 


3. Interprocess > Conpanication.... et Jaterprocess. 
vs : comsunication permits coordination.: of:..processes by | 
enabling processes’: to send. signals: to...each other. 
‘Processes may. go blocked . 44.e.:.stop;: running) and 
wait to be avekened by . anch: a signa). For example, 
-@ process): might. go bioeked .mitipg,,.to read a 
“message from a queue. Shon another process. puts a 
message. in the queue,. it can wakeup, the. : waiting 
process: who can then. reaa and pronens. the message. 


ee “AS 4 


By relaxing the - / Leatriction on the nmeber of. atone 


that a user can.create, and prowiding hetter tools for 


managing these . processes (such.as the -ability.to killa 


runaway process), processes can: be. created ag necessary. to 


perform services. A. serwice can: he reguerted; : ‘by: putting a 
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message-in a queue. Associated: with the: qnene.is:at least 
one server process. When. the: service « request is put in the 
queue, a wakeup signal. is sent: to the:«gerver associated . 
with, the queue. . If the: server is not . processing any other 
requests at the. -time;,;it would! itherny read: and: begin. to: 
pEecess the users; request, If it:..is: busy, ‘the: request. vill 
be precessed when -the .server;is-fisished)owith: thas request. 
it is busy processing. By combining message segments and 
interprocess wakeups into one facility, the entering of the 
reguest andthe notification to the server is a .single 


operation. 


After system initialization, there are no active 
servers associated with a queve. Thus, if there are any 
pending requests, or when the first request is entered, a 
process aust be created to act asa server. The description 
of the process is associated with the queue and together 
they form the representation for a service in the MNultics 
storage system. More than one process can be associated 
with the queue so that the service may handle more than one 


request simultaneously. 


‘An example of a service in the current Sultics systen 
is the output daemon which takes requests for bulk printing 


and punching. There is one server process for each output 
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device. In the current implementation, these processes are 
created when the system is initialized, or must be created 
explicitly by a operator. It is not, however, necessary to 
create these processes before they are requested. If there 
are not processes available to handle a request (and the 
maximum number of processes specified for the queue have 


not already been created), a new process can be created. 
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Functional listing of entries into the financial system. 


The financial system is —_a*¥eiieble to all other 
services of the @arketplace. Sinée’ it’ igs ¢ehtral to the 
operation of the asarketplace © aid’- £6 regal red for most 
transactions between services;> seet4al?*teonéiveration must 
be given to its implementation. For this reason, the system 
is implemented as a “Set°Of' inner ring procedures within 
Multics. To the programmer, this means that the financial 
system is accessed by using the stah@ez@ auitiee subroutine 
call mechanism. Since the syste’ 9 in'@¢°°4nhet ring, the 
user cannot make unauthorizea reterence##?o> the financial 


mon, eT 


system databases." _2tnuends tail 


The interfaces‘{orehtry points) of the financial 
System can be roughly divided into three categories: those 
that deal primarily with sanaginé! and. atcebsing services, 
those which permit management of'° ebeouNts’, antPthose which 
are used to manage individual tiwikiceone’ >> 

fe 2usere tnemyed 3 

The entries for requesting _servicey aire’> included in 

this appendix because the financial “Syites"* atts as the 


interface between the services..i© °° feusar eects 
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Entry name Page 


Services: . 


. request_service_ 
, List_pending_requests_. 
‘cancel_service_request_ 
create service,gueue 
’ 


f ee Accounts 


. Create, account. . 
‘get_pccount, states. 9... 
set_access_ | 


list_accounts_ 


R. Frankston 


eee oe . 
create.transaction_ . - 
: seta athorization_ 
set_request_anount_ 
get_paynent_status_ 
get_transaction_states, 
na key payment_ 


close, transaction_ 
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Appendix C 


assign_transaction_ 


specify_receiving_account_ 


Tables 


account_status 


financial_system_error_table_ 


transaction_status 


Page 75 


77 


96 


76 


83 


97 


Re 


Frankston 
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Name: account_status 


This is the prototype for the structure in which the 
status information for an account is returned. This 
information can be retrieved using the entry: 
get_account_status_. ag 


Format 


declare 1 account,status based, i bets 
version_ number fixed binary, ; ,- ‘is 1 *,; 
- number :of ~Bagables - fixed -binarys -: 
nuaber_of receivables fixed Sianry. 
length. Of | _access_list. fized . binary, 
balance fixed decinal(15,2), 
payables 
(0 refer (number_of_payables)), 
3 transaction_id bit @ 
2 receivables 
(0 refer (number_of_receivables)), 
3 transaction_id bit (72), 
2 access_list 
«0 Tefer(length_ of_access _List)), 
3 subscriber_nane. char (32), 
3 access flags aligned, 
owner_access bit (1), 
paymaster_ access bit (1), 
request_access bit (1), 
receiver_access hbit({t}, 
clerk_access bit (1); 


NN NN NN 


Seana ee 
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Name: assign _transaction_ 
This entry is used to give a-vendor access to set the 
requested payment amount in a transaction. It is. calied 


automatically by the request_service_ entry for the 
transaction id specified (if it is not zero). 


Usage 


declare assign_transaction_ entry( char(*), fixed 
bin(71), char(*}, fixed bin{35)); 


call assign_transaction_ _ (account_nase, 
transaction_id, assignee, status) 3: a 


1) account_nare The name of thea . account containing: the 
; transaction to be assigned. (input) 


2) transacticn_id Unigue identifier’ of transaction being 
- assigned. (input): - 
3) assignee The name of the subscriber, or service | 
to which the transaction is being 
assigned. (input) 


4) status Standard Multics status code. (outpety . 
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Name: close_transaction_ pecs ee 


This entry is used to close an open transaction. 
Closing the transaction enables paysent:: te: be made - and 
prevents further moet Ea cat ee of the anount of _ Payment 
being Oger ren” a eo YY tips Oe «= 'seayo <4 


mS 


: be ats : Cog eed? ; Paes 
Usage: se ¢ ety : on ely wie ee e 
. . oF 


declare close_transaction__ (char (*), bit(72), ‘fixea 
bin (35)); 


call close_transaction_ {account_nane, 
traapastion.id, statme) ts: ASO a tet yan 
pCzcy eid AGERE Be a 
1) account_naase The name of the sccoant in which the 
ee a a ee transection: con he teeees -tinput) 


22082 Fane. 


2) transaction_id The unique ia of the transaction... 


. (inpat). oe ret n S@an ot ote dF 
3) status are .. Stapéacd nysten: : atekus code. Is zero 


» Lfsthe trenapetion: is closed norsally. 
i a rai wip hs 


Appendix C Page 79 1/18/74 


MPM FINANCIAL SYSTEM SUPPLEMENT rEpe R. Frankston 


Name: create_account_ 


The create_account_ procedure creates a new account 
with owner's access to the specified user. The owner would 
then use additional financial routines to initialize the 
account. as desired. 


dettave create_account.| ate “ances char (*), 
char (*), fixed” bin (35)) 7. 


Usage 


> ot 


call: create.account: <> (eeebent: ake, Si1iné-adeount, 
owner_ sea eee atatus) 5 

1) wecount. hese The nare fot €44% account assigned by 
the subscriber. This name must be 
unigqee?for the’ accounts created by the 
sabscriper. ° fhe: Multics procedure 
unique, chars: '3@é@y; be used to create 
unique nares if necessary). (input) 


2) billing account The account to which is to be billed 
for the service charges for the 
creation and maintenance - of this 
account. (input) 


3) owner_name The identification of the subscriber 
who is to be given owner's access 
initially. (input) 


4) status Status returned. It is zero if the 
account has been created normally. 
{out put) 
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Name: create_service_queue_ 


This entry. is used to create a service. Associated 
with each service is a segment: in the. storage hierarchy 
that is used to store the dencri.ptd oh 0% the. SOnves, Process 
and as queue of cmiuestn for | She eens tae. » 


Usage 


declare _ create.  MORNALE smeRe! smn tKS (-: char (sys 
hae) fixed binary, fixed bin (35)) i 


<a ot s 


call : create. Spue ice asue F “(nervice, nare, 
initial_ procedure, nuaber_ of "servers, status) ; 


1) service_name The name of the service. It is the 
upathnare of.. the service. queue in the 
Aultics storage syates.. <(input) 


2) initial_procedure The .first. procedure called when the 
gervice's. process-is ‘areated. (input) 


3) numbei_of_servers The. maximum number of processes. that 
are to be available simultaneously for 
the service. : ‘Gaget) 


4) status Standard. states. ‘code. Is normally 
zero. (output) 
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Name: financial_system_error_table_ 


This is the data base in “error table" format for 
status codes from the financial system. Their meanings are 
generally chvious from their. nages., -Phea :status -code 
returned is zero if the subprocedure completed its task 
normally. a ae Bs 


account_name_invalid 
to_account_invalid 
from_account_invalid 


An account name specified:in the parameter 
list is invalid. If the calling program is not 
permitted to know that an: account exists, the 
status code for invalid accoygnt: wiklbe . given 
even if the account is otherwise valid. | 


account_already_ exists _— 


Attempt to create a new account with the same 
name as an existing account. 

no_owner_access 

no_clerk_access 

no_access_to_transaction 

no_payrmaster_access 

no_receiver_access 

no_access_ to_service 


The user does not have ‘the appropriate access to 
complete the request. 


transaction_not_found 


The specified transaction cannot be found in the 
given account. 


transaction_already_closed 
Attempt to close a transaction that is already 
closed or to change the agzount being requested 
after a transaction has been closed. 
area_too_smaall_to_return_data 
The area specified for the return of the data 
structure is too small to contain all of the 
data. The initial portion of the structure 
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containing the size of the rest of the structure 
will, however, be filled in so -that the user say 
call the entry again with an area of the 
aPPrOprLALS size. we Be) eibae oe g : 

area_too_ seall _to_ return_ size — Sd 
The area could not even contain the header a the 
structure. The user should supply a new area’ and 
attempt to call the routine — B 

service_not_found 


The specified service cannot hts yeeene in the 
oceans nce hierarchy. vee dl et 


service_queuve_ fell 


there is no room left in aks queue of requests 
for the service. : es rag Bee, 


service_out_ef_order 


The service is unavailable for an unspecified 
reason. fe a " i nee 


insufficient_balance 


The balance of the specified item is insufficient 
to satisfy the request. : 


‘Service request_not_found © © * fos 9! 


The specified pave ice: request could not be found 
in the service queue. eT cs ee nt ee 
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Name: get_account_status_ 


This entry returns a coaplete status of an account. 


Usage 
declare get_account_status_ entry ( char (*), pointer, 
pointer, fixed bin(35)); os 
call get_account_status. tscodest Sane.  area_ptr, 
status ptr, “statas) 5 vs} oh 
1) account_nare The nase of: the ‘accoont whose status is 
being a aaheetig ae) 
2) area_ptr The area in. thion “ths ‘status. sag being 
- 2 returned. . (input) * 
3) status_ptr Pointer to the structure within the 
a a area = containiig the. -status. ‘The 
structure ~~: is described in 
PACCONDTS status". sopteatl 
4) status Standard: ‘$inancial system lataiaa code. 


This is zero if.the reaueee ae tanta 
ozsat tts: omer 
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Name: get_payment_status_ 


/ This entry is -used to. retrieve. infersation from a 
transaction record. To get this information, the subscriber 
must have either access to the transaction or clerk access 
to the specified account. ; oe 


Usage 

declare get_payment_status__ ites. fixed 
decimal (15,2). : fixed cheek (15,2), fixed 
decizual (15,2), fixed 'b ¥(71), bit (1), 

char {*}. oes Sixedbinerntas) hs. oe 
call get_ payeeae status_ a (account_naze, 
_peamsectionji€, 650 0 5 ae anount_;fequested, 
' amount authorized,  §.°.. amount. paid_ sofar, 
payment_ date, acce LSCCONRE §: to account, SERERE)s 
1) aonbent ies: the. Bane - of either <eeouat ‘containing 


this transection. (input) 


2) transaction_id the * ceiaes “aentifier for this 
"Meteo transactions : Adare} tate 


3) amount_requested Phe. ancent: of: payment that has been 
requested. (output) 


&) amount authorized The amount. of payment that has been 
authorized. (output) 


5) amount_paid_sofar The amount that has actual been 
. transferred to the receiving account. 
(outpat) 


6) payrment_date The date orn. which the payrent 
authorization satures. That is, the 
date the authorized azount is to be 
transferred to the receiving account. 
(outpet) 


7) open_indicator If the value of this indicator is 
*1%b, the account is still open. This 
means that the arnount being requested 

is subject to change. (output) 


8) from_account The account from which payrent is to 
be transferred. (output) 
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9) to_account The account that is to receive 
payment. This may be blank if it has 
not been specified yet. (output) 


10) status Standard financial systen status 


code. Value is zero if data returned 
normally. (output) 
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Nage: “get_ transaction_ statas_ 
eg OP ey gy 
This entries returns the status of a transaction. 


Usage 


declare get_ ereaeecton. status_ (char (*), bit (72), 
ptr, fixed bin (35)); 


call get_transaction _status_ (account_nane, 
transaction_id, “transaction_ ptr, status) ; 


1) account_nare The name of an account containing the 
transaction. (input) 


2) transaction_id The unique name of this transaction. 
(input) 


3) transaction_ptr Pointer to a structure described in 
"transaction _status® in which the 
information is returned... (input) 


4) status Standard financial systea status code. 
Is zero if request completed normaily. 
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(zi 
Fe) 


list_accounts_ 


This: entry permits a user to get: a. cel caine list of 
accounts he cwns. 3 


Usage 
declare. list_acccunts_ (pointer, pointer, fixed 
binary (35))3. aoe 
call list_accounts_ (area_pointer, list_pointer, 
status) ; = 7 
1) area_pointer Area into which the list. of accounts is 
: retuned. (input) 

2) list. pointer Pointer to structure containing list of 
accounts.- The format of the structure 
is: 

declare 1 accoyats based{list_pointer), | 
7 2 nuaber, of. accounts fixed binary, 
2 account _nases : 
(* refer (nusber_« oF. ~accounts}) 
ead Send oo 
(outpat). sa 
3) status “Standard : néiditics status code. Is 


normally zero. (output) 


2 
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Name: list_pending_requests_ 


This entry returns a list of all: eeaeeetr “a amex has 
pending for a given service. wo 


Usage 
declare list. pending xsequests_. = ears eiraae: (*), 
pointer, pointer, fixed: binqa5}) ; 
call . list_pendiag.requette.... < (service_nane, 
area_pointer, request_pointer, : eecceay : ; 
1) service_narme™ The nape of: the service: for which the 
requests: are:to be: listed. (input) 
2) Sees Cpoiater - «Area in. -which the returned list: is to 


be allocateda.. “¢impat) 


3) request. pointer: - Pointer to -  peraetare of the following 

format: ib ween: the list of requests is 

et eent FOOD 

Seciace 1 reqtieist: dist: wines (request_pointer), 
2 nusber_requeste: fixed binary, 

2 Fegeess <f refer (nunber_requests) ) 

Skatea binary 1); Buvsts 


aide Ose ce oT gre ey co 
see SF Sb a MOE ge 


ont pats 
&) status Standard Nultics status code. 
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Name: make_payment_ 


This entry. is. used to. transfer money - between two 
accounts without a prior request for: paynent.- This means 
that there is no requested payment amount associated: with 
the transaction. 


Usage 


declare © make_paymsent_ entry ( char(*), char (*), 
bit(72), fixed dec (15,2) 85) ehar(*), fixed 
bin(35)): 


call make_payrent_ (frem:account,-. °- to_account, 
transaction ~id, amount, description, erat tel. 
1) Sco aceoane The account Eromashiich the aoney is ‘to 
be Sreneterreds: (input) 
2) to account The poco ant 46 how the. money ie to be 
noes transfebreaa hee meee 


' 3) transaction_id The identifier: for: the record of this 
payment. (output) 


4) amount < ‘The anount: af) omer. to be transferred. 
5) description | The description of this transaction. 
tinpot)s) © sep one ot i ae 
eae nF & a 


adit 


st oe A 


6) status Standard : status code. (output) 
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R.: Frankston. 


: This entry is weed. to. request a service, The internal 
iixeat: of ‘the. pareee cee: fiela eee Neco te ae. the. 


service, - 


Usage 


declare request_service_ entry( char (*), 
bing7), _ chart*) «: een eee: 


> Sin (35) 9s. © Por it 


call request_service_ 


cparaneraney negeest,_ ia, mtataal joo. 


1) service_ nane 


2) transaction_id- 
ee coos 0 7 opd <0 beamed for billing: purposes. | 


3) parameters 
4) request_id 


5) status 


Appendix c 


£ aot enee 


y 


ane of the _ service being 
a aeneeeh: f ayD. Sai i 


a 


as mee STE om cae as 


fixed 
fixed 


(service. nance, “transaction _id, 


‘requested. 


‘the sdentifier for the transaction 


If}: mot) deffenis:: breamsaction is to be 
associated with the request, a value of 


ft 


CFR R a» ee @ ¥Bq 


‘cena: is: pasweds (ingmt) «9 :- 


Pee ALY 


The pararzeters for the request. The 
4s defined by: 
ABET 


' format: G& thea: pareniiters 


the vendor of the service. 
gisqrasesbh oad? 


* 
a o 


Mk ga | 


The cul qus idegitéfier for the. requests. 


(out pat} 


_Sgseres eeupce ep Fen Ps mee ag 


The: standard Baltics status code. tt is 


normally zero. fout put) 
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ame: set_access_ 


This entry is -used to. specify the priviliges 
subscribers have with respect :to an account. The subscriber 
must have owner access. with xaspect:? to an account in order 
to set access. : 


Usage 


declare set_access. entry¢«:. char (*),.1 like 
access_structure, fixed binary (35)) ; 


call set_access_ (account_name, access_structure, 
status); 


1) account_ nase % The nane - of the account for which the 
access is being: specified. (input) 


2) access_structure Is a list of subseribers and their 
access with respect to ..an account. The 
form of the structure is: 


agar i: 


aeclare 1 access. structure, . 
2 length_ of_access_list fixed binary, 
2 access, ‘List like 
account_status.access_ list: 
(input) — 


3) status Standard Multies. status code. Is 
normally zero. (output) 
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ame: set_authorization_ 


This --entry sets the authorizetion: parameters for a 
transaction. It cannot. set the awtherizetion ‘payszent to.a- 
valve less than that already: paid. :Bhencthe date ispecified . 
is reached, the specified argount will be transferred fron - 
the "from" account's balance for the transaction's unit of 
payment. Pog th 


The user ‘must have paympaster. access: retatsee to the 
"from" account to use. this entry. , 


Usage: 
wl & ake 
declare set_authorization_ (char (*) , bit (72), 
: Char(#), fiweds cca tenigns fixed « idec(t5,2), ° 
fixed bin (35) s. ~ 297 
call set_avthorization_ = / taccount_nane,. 
transaction ay ‘azount, tote, stata): 
1) account_name The nae of an account conta tnens the 
transaction: - (mpady ) Sees 
2) transaction_id the. unique - «-$dentifier of =ssitthe 
hikes : trangzactions “tan put) 
3) amount The amount of paynent to be SRE ACE? weds 
. ae Cinpety. ah if 
4) date | the date ee is to be made. . 
(input) 
5) status Zero unless there is a failure, in 


which case it is the reason. (output) 
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Name: set_request_asount_ 


-Phis emtty sets'the-asount :-é6f gaysent; requested for a 

transaction. Yt is “valiacass LéAg BBiO Che Craxsattion | is 

open. Modify access is required on the transaction to ate 

this entry. 

| Qeciare set’ v pequést? sueant!' "ieekerieey 5 bit(72), fixed 
dec(15, 2). fixed bin (35));. 


en BSS ans oeivyileogs ytsce ts a0 
‘ealli > get _requent: anceatc” . tub= 58 qaccount_ name, 
transaction eet ere status); 
1) account_ name fee. nase:  ofcea: ‘account. eee sine the 
frassaction. (inpat) 
3 Paar - A f a “4 ite & 2k VORB cd: id 
2) transacticn_id The antoees ae of. " the. “transaction. 
(apet) een gh es 1 
3) amount mee Anoeet: of : 2 payment. “being requested. 
. (input) . - 
&) status | | Watastaka financial ate States Eode: 
(output) 


Appendix C Page: 95 ~ 27 W748 7:74 


MPM FINANCIAL SYSTEM SUPPLEMENT . R. Frankston 


Name: specify_receiving_account_ 


This: entry: is used’ by a vendor’‘who has: been assigned a 
transaction. te specify © the acconpt.to which payment is to 
be made. : eS yp eepmeey ety, ae 


Usage 
declare specify_receiving account_*« entry (char (*), 
fixed. ban (71) acchart*),: fixed: -bin4{353); 
eats specify _ receiving. account_ (account_nane, 
aepanances oe eee Receiving. account, statas) ; 
a Ey. ROL TORE OBES 
1) account_nare Hane ~ ‘the “account containing the 
: Yh te transactions :. apc gent thegue 
2) transaction_id Identification of the trsaction. 


. (inpet).; ee eae 


3) Hecesyaese account The nare oe the account which is to 
$ : receive Ba yaemt«: -d{input) . - : 


4) status orandard aitics status code. 


3 
& 
TA be 
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ame: transaction_ status: 


Structure in nich “the lcs of a transaction is 
returned by get_transaction_status_. 


Format 


declare 1 transaction _status:baseda,: = 


Appendix C 


2 transaction_ id bit (72), 


2s pavingsac@enat CheR{B2dac.° /*.f¥om.acct */)- 


2 receiving account char (32), /* to acct */ 
2 amount_ —Tequestedcfineds dee (ass 23 62Eg Lo TS 
2 amount_paid_sofar fixed dec(15,2), 

2 amount_authorized fixed dec(15,2), 

2 payment_date fixed bin(71), 


1 2-payes,pame char (32) e¢20cei8 24s 


2 receiver_nase char (32), y* ‘for ‘reference 7 
2% opeazfiag: DIt{s) +. ePa G0 ames 2 bak Aer re: 
2 request_change_ access char (32), 


2 description_length figed: bisary(35) ,-. 
2 description char (* refer (description, length) ): 
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